The increasing number of financial and personal transactions being performed on local or remote microcomputers has given impetus for the establishment of “trusted” or “secured” microprocessor environments. The problem these environments try to solve is that of loss of privacy, or data being corrupted or abused. Users do not want their private data made public. They also do not want their data altered or used in inappropriate transactions. Examples of these include unintentional release of medical records or electronic theft of funds from an on-line bank or other depository. Similarly, content providers seek to protect digital content (for example, music, other audio, video, or other types of data in general) from being copied without authorization.
A system that may operate from time to time in either a trusted or an untrusted mode, or both simultaneously, may encounter a security issue with certain error reporting implementations. For example, in the Pentium®-compatible architecture a hardware error reporting system, called a machine-check architecture (MCA), is provided. The MCA may provide a mechanism for detecting and reporting hardware errors, such as system bus errors, error-correcting code (ECC) errors, parity errors, cache errors, and translation look-aside buffer (TLB) errors. The MCA may include a number of MCA-supporting registers that may be used for recording information about errors that may be detected. The MCA registers may have potential security sensitive information written to them in the event of a hardware failure during operation in a trusted mode. To better support the subsequent execution of diagnostic software, the contents of these MCA registers may survive across a processor reset event.
In some processor embodiments, there may be an internal debug flag that may influence access to yet further hardware test and debug hooks. For example, if the internal debug flag is set, access may be granted to internal processor node states that would not be available during normal processor operation. This flag may be set during manufacturing and final test, and cleared during preparation for delivery to an end user. In other embodiments, other control methods for the internal debug flag may be implemented.